1. Field of the Invention
The present invention relates in general to the field of information processing, and more specifically to a system and method for checking consistency of configuration models against predetermined rules and assumptions using flexible rule space subsets.
2. Description of the Related Art
A configurable product can be described by a configuration model having a set of configuration rules. A configurable product can be conceptually broken down into sets of selectable families and features of families that make up each product. A family represents a classification of a particular type of feature. Families are typically classified as groups of features with the same functional purpose. Example families for an automobile are “engines,” “tires,” “seats,” and “exterior paint color.” Families can be represented in terms of the minimum and maximum number of features that must be present in a configuration from a family for the configuration to be valid. A common family minimum and maximum or “(min, max)” is (1, 1). This notation means that exactly one feature from the family must be part of a configuration for the configuration to be valid. Other common (min, max) settings are (0, 1), meaning that either no features or a single feature from the family must be present in a configuration for it to be valid, and (0, −1), meaning that zero or any positive number of features from the family must be present in a configuration for it to be valid.
A feature represents an option that can be ordered on a product. All features are members of a family. Features are both assigned optionalities and used to qualify other features and the optionalities assigned to them. An example feature from the engine family is a “4.8 liter V8.” Features relate to each other via ordering codes or optionalities. Example optionalities include “S”, “O”, “M”, and “N,” which translate to standard, optional, mandatory, and not available. A specific example would be “the 4.8 liter V8 engine is standard on the GS trim.”
A configuration rule includes a main feature, an optionality, one or more constraints, and an applicable timeframe. As an example:
Main featureOptionalityConstraintsTimeframe4.8 liter V8SXL & USMay–DecemberRule 12003
Rule 1 means “the 4.8 liter V8 is standard with the XL trim and US market from May to December 2003.” The main feature represents the feature that is being affected by the rule. Optionalities can be positive or negative: positive optionalities state that the main feature can work with the constraints; negative optionalities state the main feature cannot work with the constraints. Constraints qualify the rule and can be an arbitrary Boolean expression of features such as AND, NOT, and OR operators. The timeframe specifies when the other rule elements are effective.
A configuration buildable describes what features can and can't exist with other features of a product. The example rule above defines a buildable configuration in the following way: “the 4.8 liter V8 is buildable (because it is standard) with the combination of XL and US.” If the combination of features, such as of XL and US, is not buildable, the example rule is inactive. Consequently, even though the engine is buildable with that combination, if the combination is not buildable, the three features together are not a buildable configuration. A rule that would make the example rule inactive is the following:
Main featureOptionalityConstraintsTimeframeXLNUSSeptember 2002Rule 2
Rule 2 means “the XL trim main feature is not available with US from September of 2002 onward.” Until the XL main feature is made available with the US by changing the optionality from “N” to one that expresses a positive relationship, there will not be a buildable configuration for XL, US, and the 4.8L engine.
Thus, a rule defines a buildable configuration between its main feature and its constraints only. A rule does NOT define a buildable configuration relationship between the members of its constraints. A separate rule must define that buildable configuration. Consequently, all rules together for a product define the complete product buildable configurations. In order to determine if the three features in the example rule (the main feature and the constraints) are a buildable configuration, the rules written on each of those features (i.e. where each feature is the main feature) need to be considered jointly. Inactive rules do not define buildable configurations until they become active.
Inconsistencies between rules represent a significant concern when modeling a product using rules. Inconsistencies among rules in configuration models result in errors that negatively impact the usability of a configuration model. Inconsistencies can occur due to modeling mistakes or due to multiple parties generating rules for the same configuration model. Thus, detecting inconsistency errors through consistency checking plays an important role in developing useable, robust configuration models.
For example:
Main featureOptionalityConstraintsTimeframeXLNUSSeptember 2003Rule 3XLSUSSeptember 2003Rule 4
Rule 3 and Rule 4 are inconsistent because Rule 3 signifies that the feature XL is not available in the U.S. market, and Rule 4 signifies that the feature XL is standard in the U.S. market. As the number of rules grows, the ability to detect inconsistencies becomes more challenging.
FIG. 1 depicts a set of rules 100 with features F1–F4 of a single family, optionalities, and constraints represented by families A, B, C, D, E (each having “X” number of features). FIGS. 2 and 3 depict the rules of FIG. 1 in respective grids 200 and 202 and illustrate two conventional ways of detecting inconsistencies between rules. In FIG. 2A, each cell in a column is compared against every other cell in a column. An inconsistency error exists if two cells with a column have inconsistent optionalities or other assumptions are violated, such as a lack of a standard configuration in a column. Some configurable products have tens of thousands or hundreds of thousands of rules defining buildable configurations. As the number of rules and, thus, columns in the grid of FIG. 2A grow, column by column inconsistency checking becomes very computationally time consuming.
FIG. 2B depicts a variation on the column-by-column consistency checking approach of FIG. 2A. In FIG. 2B columns with identical optionalities are grouped together. Thus, the number of consistency checking operations is reduced; however, this can still result in long periods of computational processing.